home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001460_daemon _Sun Jun 27 00:05:26 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  2KB
  1. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  2.     id AA02158; Sun, 27 Jun 93 00:05:27 MET DST
  3. Return-Path: <marca@wintermute.ncsa.uiuc.edu>
  4. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  5.     id AA02154; Sun, 27 Jun 93 00:05:26 MET DST
  6. Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  7.     id AA19040; Sun, 27 Jun 1993 00:28:40 +0200
  8. Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA03189
  9.   (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sat, 26 Jun 93 17:28:34 -0500
  10. Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
  11.     for @newton.ncsa.uiuc.edu:wmperry@nectarine.ucs.indiana.edu id AA16184; Sat, 26 Jun 93 17:31:20 -0500
  12. Date: Sat, 26 Jun 93 17:31:20 -0500
  13. From: marca@ncsa.uiuc.edu (Marc Andreessen)
  14. Message-Id: <9306262231.AA16184@wintermute.ncsa.uiuc.edu>
  15. To: Rob Raisch <raisch@ora.com>
  16. Cc: "William M. Perry" <wmperry@nectarine.ucs.indiana.edu>,
  17.         www-talk@nxoc01.cern.ch
  18. Subject: Re: Suggestion for a new URL type 
  19. In-Reply-To: <Pine.3.03.9306261536.R5397-b100000@amber.ora.com>
  20. References: <8346.741121113@nectarine.ucs.indiana.edu>
  21.     <Pine.3.03.9306261536.R5397-b100000@amber.ora.com>
  22. X-Md4-Signature: ce47f66dc37ae4e724caf2d5c070210a
  23.  
  24. Rob Raisch writes:
  25. > If a dedicated cracker wishes to break the system, I would suggest
  26. > that writing an HTML document, and using that as a lock pick on
  27. > doors which have no locks to begin with, would be a marvelous
  28. > exercise in stupidity.
  29.  
  30. This is true in and of itself.  However, the true danger is that this
  31. is would be a remarkably efficient way to trick other people into
  32. doing things not in their best interest (as Marc VH points out) and
  33. therefore I think this is a bad road to travel down.  Let's keep such
  34. functionality on the server/gateway side; it is easy enough to write
  35. gateways as it is (and in fact it would be trivial to write a gateway
  36. to accomplish exactly the functionality Rob describes).
  37.  
  38. Marc
  39.